home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
telnet
/
telnet-minutes-90dec.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
7KB
|
197 lines
CURRENT_MEETING_REPORT_
Reported by David A. Borman/Cray Research, Inc.
TELNET Minutes
Agenda
o Telnet Environment Option
o Telnet Authentication Option
o Telnet Encryption Option
o Telnet Specification
Telnet Environment Option
The Telnet Environment Option had been passed off for publication as a
proposed Internet Protocol. However, some members of the IAB expressed
some concerns about the possible misuse of the option, mainly that it
might be used to create proprietary, non-interoperating telnet
implementations.
In May of 1990, the ``Well Known Variables'' section was removed from
the draft document due to of lack of consensus on what would be the well
known variables. From the minutes of that meeting:
o Section 6, ``Well Known Variables'' was discussed at length.
People disagreed what the user account name variable should be,
USER or USERNAME (some systems use LOGNAME). The group could not
agree on what would be the best names for well known names, whether
they should have a consistent format, (e.g., a common prefix) or
whether there should be a common prefix for user-defined variables.
Because resolution was not reached, it was decided to strike
section 6 from the document, but leave in the names in the example
section. It was agreed that well known names could be added later
if consensus was reached on the naming scheme.
o Possible action items for this document:
- Issue it as is, as an Experimental RFC.
- Define a ``Well Known Variable'' list, and re-submit for a
proposed standard.
- Decide if non-standard variables would be allowed. Some
1
suggestions:
* names of the form X-*, like mail
* use a STD- prefix for standard names
* use <system-type>- prefix
- Since the Environment option is based on UN*X environment
variables, should we be blatant about a UN*X bias?
- Put the well-known variable names in the assigned numbers
document.
- Use SNMP to manage well-known variable names?
Items 1 and 2: After discussing the pros and cons of each of these, it
was decided that the document would be re-submitted as is, to be
published as an experimental RFC. This would allow the document to get a
wider distribution.
On item 3, the consensus was that non-standard variables need to be
allowed; by limiting it to just well-known variable names, much of the
usefulness of the option would be removed. No agreement was reached on
how to name the standard vs. non-standard variable names, and the
discussion was deferred to the mailing list.
Item 4 was rejected; just because the option maps nicely onto the UN*X
platform does not limit it to just UN*X machines, and there is no reason
to perpetuate that myth.
Item 5 was agreed on, once the format and names are decided upon. The
list of ``Well Known Variables'' will contain the variable name, and a
description of any syntax that is to be applied to the value of the
variable.
Item 6 was brought up as an interesting way to manage variable names,
but was dismissed as not being appropriate, since SNMP deals with
variables on a machine level basis, and the Telnet Environment Option
deals with variables on a per-user basis. This would also open up a big
can of worms with regard to security.
Telnet Authentication Option
2
Several minor modifications were made to the Authentication document:
1. The user name that is being authenticated must now be passed as
part of the authentication negotiation, not in the (proposed)
ENVIRON option. This change has two advantages:
o It makes the Authentication option self contained.
o It allows the user to authenticate as one person, but have a
USER variable of someone else, e.g., use the Authentication
option to authenticate as ``root'', but use the ENVIRON option
to set the USER variable to ``joe'', so that the user can be
``root'' with ``joe's'' environment.
2. Previously the document said that the server side SHOULD send the
DO AUTH, and the client WILL AUTH. The SHOULD has been changed to
MUST. If the server(client) receives (DO(WILL) AUTH), the option
MUST be refused.
3. There was discussion about changing from the current
(SEND/IS/REPLY) to a separate (SEND/IS) negotiation, followed by a
(CLIENT_DATA/SERVER_DATA) negotiation. This idea was voted down.
4. The PRIVATE type was eliminated; this would only lead to
non-interoperable implementations.
5. The type NONE was changed to type NULL, and it is the type returned
by the client when it does not support any of the authentication
types proposed by the server.
6. The type LOGIN was removed.
7. There was discussion about what exactly the authentication option
gives the user. It does not give integrity. Once the
authentication is completed, the connection could be taken over
and/or modified by some intervening host. The encryption option
should be used to gain data integrity. There was discussion about
whether or not the ability for one side of the connection to
``challenge'' the other side would be useful; it was decided that
all that that would do is make it harder for the connection to be
taken over/modified, but would not eliminate that possibility.
8. The type KERBEROS was split into two type,KERBEROS/_V4 and
KERBEROS/_V5. New types for SPHINX and MINK will be added.
Time did not allow for the discussion of the Encryption Option or the
Telnet Specification.
3
It was decided that at the next IETF meeting, the Telnet WG would meet
for two sessions (a 3 hour and a 2 hour session).
Attendees
David Borman dab@cray.com
Philip Budne phil@shiva.com
Anthony Chung anthony@hls.com
George Conant geconant@eng.xyplex.com
Steve Crocker crocker@tis.com
James Dray dray@st1.ncsl.nist.gov
Peter Ford peter@lanl.gov
James Galvin galvin@tis.com
Robert Gilligan gilligan@eng.sun.com
Russell Hobby rdhobby@ucdavis.edu
Joel Jacobs jdj@mitre.org
Philip Karn karn@thumper.bellcore.com
Darren Kinley kinley@crim.ca
John Linn linn@zendia.enet.dec.com
E. Paul Love Jr. loveep@sdsc.edu
Joyce Reynolds jkrey@isi.edu
Kary Robertson
Jeffrey Schiller jis@mit.edu
Sam Sjogren sjogren@tgv.com
Pat Smith psmith@merit.edu
Mark Stein marks@eng.sun.com
Emil Sturniolo
Dean Throop throop@dg-rtp.dg.com
Jesse Walker walker@eider.enet@decpa.dec.com
Kathy Wilde wilde@decvax.dec.com
4